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(54) System and method for executing verifiable programs with facility for using non-verifiable 
programs from trusted sources 



(57) A computer system includes a program execut- 
er that executes verifiable architecture neutral programs 
and a class loader that prohibits the loading and execu- 
tion of non-verifiable programs unless (A) the non-veri- 
fiable program resides in a trusted repository of such 
programs, or (B) the non-verifiable program is indirectly 
verifiable by way of a digital signature on the non-veri- 
fiable program that proves the program was produced 
by, a trusted source. In the preferred embodiment, veri- 
fiable architecture neutral programs are Java bytecode 
programs whose integrity is verified using a Java byte- 
code program verifier. The non-verifiable programs are 
generally architecture specific compiled programs gen- 
erated with the assistance of a compiler Each architec- 
ture specific program typically includes two signatures^ 
including one by the compiling party and one by the 



compiler. Each digital signature includes a signing party 
identifier and an encrypted message. The encrypted 
message includes a message generated by a prede- 
fined procedure, and is encrypted using a private en- 
cryption key associated with the signing party. A digital 
signature verifier used by the class loader includes logic* 
for processing each digital signature by obtaining a pub- 
lic key associated with the signing party, decrypting the 
encrypted message of the digital signature with that 
public key so as generate a decrypted message, gen- 
erating a test message by executing the predefined pro- 
cedure on the architecture specific program associated 
with the digital signature, comparing the lest message 
with the decrypted message, and issuing a failure signal 
if the decrypted message digest and test message di- 
gest do not match. 
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BACKGROUND OF THE INVENTION ^^^^^ eharactens.ics ol a 

. Hpfined lor the purposes ot this '°^Zers ,BN/lPCcompatik).ecorT.puters 

^^^^^^^^^^^^^ 

using the DOS or Windows ^P^f^^, operating system. ^^,3, ,0 abil.ty ot certain programs. 

The term "architecture ^P^^'= ,a«orms using a single ^^^^'''^'^^^^^^^ ^^i^g the IBM PC compatible 

programs to t,e executed o^V « ^^^^^.^.^e can only t>e oro 
programs written .n the 80486 ass ,ers that contains IBM PC comp independence ol pro- 

computer architecture (as ^-1^^^^'';;^ programs (ANPrograms) '"/'"'^^^f ^^^^^^^^ programs can be ex- . 

ir^portant features ol 3^'=,^"^^"^"'^ "^"^^gjage (ANLanguage). For ^^^'^^'^;^^^^J^^^, ,eature of Java bytecode 
grams written in the arc*^itec -e neu^^ Sa bytecode interpreter. An ad«, .m^orlan ^^^^^^^^ ^ ^^^^ ^ 
ecuted on any computer P'^^ ^^^^^^^^^^^.^y verified prior to execution by ^ Java by^ ^^^^^^^ 3^3,, 

programs is that their " '^^''^Sorms to predetined integrity cruena Such cr^ ^^^^^^ ^^^^^..g 

vermer determines whether the Program co bytecode programs cannot overtiow ^^^^^^ ^ ^^^^ 

bytecode program cannot create ec Po ANProgram to run less efficiently 

the user has explicitly granted J P^J^^^^f in an ANLanguage "^^^^f^^J'/j^.a Jecode programs executed 

unfortunately, distributing ^''f^^'^^^'^^^^^^^^ programs 

loss 01 efficiency that some users will requ ^^^^^^^ ^^^^ 

sirable to have a computer system '"^ ASPrograms. ,„^„,ations require that the third party be 

the capability of executing '"^^S J Y 3 third party is possible. ^""j^^^^^^^'S ASP^ogram that it was compiled 

Although compilation of f^P^^Jl^^^ J^enfy from the information in the comP ^ « ASProgram 

'verifiable manner identifies the correspo ^^^^^ ^^^^ 

,t was compiled. „„ontion orovide an ANProgram compiler ana co v compiled the 

integrity verrtiable ANPrograms being execut 
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verifiable sources and compilation informaiion so that essentially all legitimate tasks can be performed while preventing 
from being called ASPrograms whose sources, compilation information, and integrity cannot be venfied. 

SUMMARY OF THE INVENTION 

In summary, the present invention is a program executer that executes verifiable architecture neutral programs, 
and a class loader that prohibits the loading and execution of non-verifiable programs unless (A) the non-verifiable 
program resides in a trusted repository of such programs, or (B) the non-verifiable program is indirectly verifiable by 
way of a digital signature on the non-verifiable program that proves the program was produced by a trusted source. 

In the preferred embodiment, each verifiable program is an architecture neutral program embodied in an object 
class having a digital signature that includes a message digest uniquely associated with that program. 

Non-verifiable programs are embodied in object classes that contain a keyword indicating that the program (called 
a method) is not a verifiable program. In the preferred embodiment the non-verifiable programs are generally archi- 
tecture specific compiled program generated with the assistance of a compiler. Each such object class includes: 

the compiled, architecture specific code: 

if there is a corresponding architecture neutral program (which sometimes there is not), information identifying the 
corresponding architecture neutral program, including a copy of the message digest of the corresponding archi- 
tecture neutral program: 

a digital signature by the trusted "compiling party" that generated the object class (e.g. . by performing a compilation 
of a source program), signed using the compiling party's private encryption key: and . if the code in the object class 
was generated by a compiler, a digital signature by the compiler itself, signed using the compilers private encryption 

• key. 

A generally available, trusted repository of public encryption keys, sometimes called a naming service, holds the 
public keys for the compiler and the trusted compiling party. Using these public encryption keys all recipients of the 
object classes having non-verifiable programs can decrypt the digital signatures in the object class to verify that the 
object class was created by a trusted party, to verify that the non-verifiable program code in the object class was 
generated by the indicated compiler (if any), and also to verify the identity of the corresponding architecture neutral 
program (if any). Optionally, when the non-verifiable program code in the object class has a corresponding verifiable 
program, the potential user of the object class can use the program verifier to verify the proper operation of the corre- 
sponding verifiable program prior to executing the non-verifiable program code in the object class. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Examples of the invention will now be described in conjunction with the drawings, in which:- 
Fig. 1 is a block diagram of a distributed computer system incorporating a preferred embodiment of the present 
invention. 

Fig. 2 depicts the structure of an architecture neutral program in accordance with a preferred embodiment of the 
•^0 present invention. 

Fig. 3 depicts the structure of a compiled, architecture specific, program generated in accordance with a preferred 
embodiment of the present invention. 

Fig. 4 depicts an object and associated object class in accordance with a preferred embodiment of the present 
invention. 
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DESCRIPTION OF THE PREFERRED EMBODIMENTS 

Referring to Fig. 1 . there is shown a computer network 1 00 having many client computers 1 02, a server computer 
104. and a trusted key repository 106. The client computers 102 are connected to each other and the server computer 
104 and the trusted key repository 106 via a network communications connection 108. The network communications 
connection may be a local or wide area network, the Internet, a combination of such networks, or some other type of 
network communications connection. 

While most of the client computers 102 are desktop computers, such as Sun workstations. IBM compatible com- 
puters, and Macintosh computers, virtually any type of computer could be a client computer. Each of these client 
computers includes a CPU 110, a user interface 112, a memory 114, and a network communications interface 116. 
The network communications interface enables the client computers to communicate with each other, the server com- 
puter 104. and the trusted key repository 108 via the network communications connection 106. 

The memory 1 1 4 of each client computer 1 02 stores an operating system 1 1 8. a network communications manager 
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120 an ANProgram (architecture r^eutral program, executer 122. an ASProgram (arch lecture ^P«f 
120. p ' ,1 verifier 126. an ANProgram compiling preparer I2e. a signature generator 130. a 

cuter 124. ^%^''^'^'^'^^^Xq lio^n^aU^ (Complnfo) verifier 134, an object class loader 136 a user address 
signature verif er 32, a Wl.^^^ ^ an untrusted object class repository 142, and lists 144 of known, 

space 1 36, a trusted J^f .^^^^^^ operating sys em .s run on the CPU 110 and controls and coor- 

raTes rn^ig re"s r2rror : CPU fn r^^s^e t^ commands .ssued by a user with the user inte.ace 

^ " The ANProgram executer 122 o, each ^^—^ 

-fSS=rm^:is^^ 

^NP^a^rgS 1 S r ;o^::cr brr Sng . the .ogr^ sat.sf ies the predefined integrity 

c^teria%heseALro„^^^ 

' meXprrTexS Ter 5::^ ih^A^^^^ verifier 124 are respectively a Java by.ecode program inter- 

prier and r;avrbTt:Sde pr^^^^^^ verifier that respectively execute and venfy the Java bytecode programs. The 
lav/a hx/tecode verifier and interpreter are products of Sun f\/icrosyslems, Inc. 

Howevef e^^^^^^ computer 102 has an associated specific architecture for which programs may be wntten -n 
.IninnT^^^ executed by the ASProgram executer 1 22. The ASLanguage does not require that 

HPS =S^^^^^^^^ 

cLS »»S *nroo^;fec.° me oo.pL.d ASP,o9-am. are going ,o be Cie.nbu.ed ^ .»cu,e<. b, « ASPro- 

gram executers 124 of other client computers. 

Preparing an Architecture Neutral Program for Compiling 

t'::tc::™.zz ^e^rrbre—"^,,, .o. « po^bose. « « le ^.^ » 

AN Program integrity verifier sends back a failed result to the ANProgram compiling preparer In response the AN 
P^ograr^ compiling preparer aborts the compiling preparation procedure and generates an appropriate message ind. 

'^'However if the ANProgram code 202 does satisfy the predefined integrity critena. then the ANProgram inlegriW 

generator generates the Dig.talSignatureop by first generating a "^^^^^^^^^ f <'^°o;^ A.^p°olm c^^^ hash 
202 It does this by computing a hash function. HashFunctionop, on the data bits of the ANProgram c"^®- ' "~ 
function used be eUher a predetermined hash function or one selected by the OrigPaay For P^^PO^^^ °' 
docu-nt fherashFunctionoP corresponds to the OngParty since i. was used for the DigitalS.gnatureop of the Or.g 

''''The Signature generator 130 then encrypts the generated massage digest (MDop) 212 and the ID of the Hash- 
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FunctionQp (HashFunctionQp iD) 2i4 with the private encryption key of the OrigParty (OrigParty's PrivateKey). The 
signature generator then adds the OrigParty's !D 215 in clear text at the end of the encrypted iienns 21 2 and 2i4 to 
form the DigitalSignatureop. The OrigParty's PrivateKey and ID are provided by the OrigParty with the user interlace 
112. 

5 After the DigitalSignatureop 21 0 is generated, the ANProgram compiling preparer 1 26 appends it to the ANProgram 

code 202. Then, the ANProgram compiling preparer generates a message that the ANProgram 200 has been prepared 
for compiling by the server computer 104. 

The OrigParty then issues with the user interlace 112 a command to the network communications manager 120 
to transmit the ANProgram 200 to the server computer 104, along with arguments specifying the architecture specific 

10 language into which the program is to be compiled (ASLanguage ID) and the compiler to be used (Compiler ID). The 
network communications manager retrieves the ANProgram from the trusted or untrusted object class repository 140 
or 142 in which it is located and provides it to the network communications interface 116. The network communications 
■ manager then instructs the network communications interface to transmit the ANProgram to the server computer along 
with the specific arguments. 

15 

Compiling an Architecture Neutral Program 

The transmitted ANProgram 200 is then received at the server computer 104. The server computer includes a 
CPU 150. a user interface 152. a memory 154, and a network communications interface 156. The network communi- 
20 cations interface enables the server computer to cornmunicate with the client computers 102 and the trusted key re- 
pository 106 via the network communications connection 108. 

The memory 1 54 of the server computer 1 04 stores an operating system 1 58, a network communications manager 
160, an ANProgram compiler 162, a signature verifier 164. an ANProgram integrity verifier 166. a signature generator 
168. an ANProgram repository 170. and an ASProgram repository 172. The operating system is run on the CPU 150 
25 and controls and coordinates running the programs 160-168 on the CPU in response to commands issued by a com- 
piling party (CompParty) with the user interface 152. 

The network communications interface 156 receives the ANProgram 200 and instructs the network communica- 
tions manager 160 that this has occurred. In response, network communications manager places the received ANPro- 
gram in the ANProgram repository 170. It the server 104 is set up as an automatic compiler service, this is done 
30 automatically by the network communications manager 160. Otherwise, the ANProgram is moved into repository 170 
by the network communications manager when the CompParty issues a command with the user interface. 

Then, either automatically or upon the issuance of a command by the CompParty with the user interface 252, the 
ANProgram compiler 162 is invoked to compile the ANProgram 200. Table 2 contains a pseudocode representation 
of the compilation procedure used by the ANProgram compiler to compile the ANProgram. 
35 Referring to Figs. 1-2 and Table 2, the ANProgram compiler 162 first calls the signature verifier 164 to verify the 

DigitalSignatureop 210 in the received ANProgram 200 so as to establish that the DigitalSignatureop 210 is actually 
the originating party's signature for the ANProgram (e.g.. as opposed to being a forged signature or the OrigParty 
signature on some other version of the ANProgram). In particular the signature'verifier uses the ClearText OrigParty's 
ID 216 in the received ANProgram to obtain the OrigParty's PublicKey from the trusted key repository 106. Then the 
■^0 signature verifier decrypts the encrypted MDqp 212 and HashFunctionop ID 214 in the DigitalSignatureop using the 
public encryption key of the OrigParty (OrigParty's PublicKey). 

Next, the signature verifier 164 generates a test message digest (Testr^Dop). which should match the decrypted 
IVIDop 212. by computing the corresponding HashFunctionop on the ANProgram code 202 of the received ANProgram 
200. The HashFunctionop ID 214 in the decrypted DigitalSignatureop is used to identify the proper HashFunctionop 
to be used. The decrypted MDqp and the generated TestMDop are then compared to verify the DigitalSignatureop 210. 

If the tJ^DQp 212 and the TestMDop do not match, then the signature verifier 162 sends back a failed result to the 
ANProgram compiler 162. In response, the ANProgram compiler aborts the compiling procedure and generates an 
appropriate message. 

On the other hand, if the MDqp and the TestMDop rnatch, then the signature verifier 162 sends back a passed 
so result to the ANProgram compiler 162 and the ANProgram compiler calls the ANProgram integrity verifier 166. It in- 
structs the ANProgram integrity verifier to verify the integrity of the ANProgram code 202 of the received ANProgram 
200. This is done in the same manner and for the same purpose as was described earlier in the section discussing 
preparing the ANProgram for compiling. Thus, if the ANProgram code does not satisfy the predefined integrity criteria, 
the ANProgram integrity verifier sends back a failed result to the ANProgram compiler In response, the ANProgram 
55 compiler aborts the compiling procedure and generates an appropriate message indicating this. 

However if the ANProgram code 202 of the received ANProgram 200 does satisfy the predefined integrity criteria, 
then the ANProgram integrity verifier 1 66 sends back a passed result to the ANProgram compiler 1 62. The ANProgram 
compiler then compiles the ANProgram code into the ASLanguage identified by the ASLanguage ID specified by the 
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.owtnP,n<. 1 3 and Table 2 the compiler places the ANProgram code 202. the DigitalSignalureop 
OngParty^Refernng now to F,g^^^ ^^^^ ^^^^^^ ASProgram repository 172. 

210 and '^^^^^'^^'^'^''Z^^^^^ ger^erator 168 ar.d instructs ,t to generate the ANPrograrr, 

The ANProgram ^^-^P \f ^ the" c^^^ 320 wNch can be ver.fied to ensure that the ASProgram 300 was corn- 
compiler's digital signature (D'9'«a'S'9naturec) 320 whici^^can o descnbed earlier for generating the 
pned With the trusted ANProgram cor^p er. Th.s .s ^^^^^^^""^^^^^^^^ ^sp.^gram code and the Digita.Signa- 
DigitalSignatureop. However, .n th.s case, the set of '^.^^ ,D 334 may be used to generate 
tureop Another ^^^^^^^^^ l~m4T^^^^^^^^ - ~ 
the message digest MDc 322 ° ,3^^ to encrypt the MDc and the HashFunctionc ID. and 

t"e^rn" eTorANrg^r --r '^r 

»:£Z'£ZX^^^^ Of this disclosure, the HashFunct.oncp corresponds to the CompParty since ,t was used 
for the DigitalSignaturecp of the CompParty. HashFunctioncp (HashFunctiohcp ID) 

The signature generate. 168 then ^"^-^Pj^^^^^^^^^^^^^ The signatu"; generator then adds 

components in it: 



ANProgram Code. 
DigitalSignatureop^ 
ASProgram Code. 
DigitalSignaturecr and 
DigitalSignaturecp 



Then the ANProgram compiler generates a message that the ANProgram 200 has been compiled to form the ASPro- 

the OrigParty's client computer 

Object and Object Class Creation and Distribution 

« ^ AQDr^nr=,m ^HQ is then reccivGd bv the communications interface 116 of the OrigParty's client 

to the native program. Similarly, for ^^^^^^^^^^^^^^ Every object 420 of this object class includes 

(ANProgram ID) 416 and a corresponding pointer 418 to tne AiNKrogrdrn. cvc.y j 
an object header 422 that points to the object class 400. 
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Thus, the OrigPany may create an object 420 and an object class 400 with the ASProgrann 300 that was received 
from the server computer 104 as one of the ASPrograms 402 in the object cfass. 

When the OrigPany wishes to distribute to various ExecuteParties an object and object ciass that includes the 
ASProgram 300 and ANProgram. then the OrigParty issues a command with the user interface 112 to instruct the 
network communications manager to transmit these items to the client computer 1 02 of the ExecuteParties. The network 
communications manager does this by retrieving them from the untrusted object class repository 142 in which they are 
located and provides them to the network communications interface 116 with appropriate transmission instructions. 
Altemately. the network communications manager of the OrigParty may respond to a request initiated by an Exe- 
cuteParty for a copy of a specified object class 400. 

Execution of Architecture Neutral Programs and Architecture Specific Programs in an Object Class 



The network communications interface 156 of the client computer 102 receives the transmitted object and object 
class and instructs the network communications manager 160 that this has occurred. In response, the ExecuteParty 
'5 issues a command with the user interface 1 1 2 to instruct the network communications manager to retrieve the received 
object and object class from the network communications interface. The network communications manager then stores 
the received object and object class in the untrusted object class repository 142. 

The untrusted object class repository 142 of each client computer 102 contains the objects and their associated 
object classes that are not trusted. These object classes are not trusted because any ANPrograms they include have 
20 not yet had their integrity verified and any ASPrograms they include have not had their source verified nor have been 
verified as being compiled from the proper ANProgram. 

The trusted object ciass repository 140 of each client computer contains the objects and their object classes that 
are trusted. These object classes are trusted because any ANPrograms they include may have already had their 
integrity verified by the ANProgram integrity verifier 136 and any ASPrograms they contain have been ascertained to 
2S be trustworthy. In fact, some or all the object classes in the trusted object class repository 140 need not have digital 
signatures, because these object classes are trusted and therefore there is no reason to perform integrity checks on 
the methods in these object classes. 

It is desirable to have an object class that primarily includes ANPrograms but may also include ASPrograms so 
that essentially all legitimate tasks can be performed with the object class, as suggested earlier. Therefore, the AN- 
20 Program executer 122 is capable of executing integrity verifiable ANPrograms and calling the ASProgram executer to 
execute integrity non-verifiable ASPrograms that are either (1) in trusted object classes in the trusted object class 
repository 1 40, or (2) that are in untrusted object classes in the untrusted object class repository 1 42 and have verifiable 
DigitalSignatureop, DigitalSignaturecp and DigitalSignaturec information so that essentially all legitimate tasks can be 
performed. In this way. ASPrograms of untrusted object classes that don't have DigitalSignatureop, DigitalSignaturecp 
2S and DigitalSignaturec information or whose digital signatures cannot be verified are prevented from being executed. 
Table 3 contains a pseudocode representation of the execution procedure used by the ANProgram executer 

Referring to Figs. 1-4 and Table 3. at the client computer 102 of an ExecuteParty (e.g.. the OrigParty or another 
party): the ANProgram executer 1 24 may be executing an ANProgram that seeks to call a method in a specified object 
class. The method call is initially handled by the object class loader 136. which determines whether or not the object 
class has already been loaded. If the object class has already been loaded into the ExecuteParty's user address space 
138, then the ANProgram executer 122 executes the called method if the called method is an ANProgram and the 
ASProgram executer 124 executes the called method if the called method is an ASProgram. 

However if the object class has not yet been loaded into the ExecuteParty's address space 138, then the object 
class loader 1 36 loads the object class into the ExecuterParty's address space and determines whether or not execution 
of the called method is to be allowed. For instance, if the object class was loaded from the trusted object class repository 
140, then execution of the called method is permitted and the Execute procedure is called. The Execute procedure 
(see Table 3) calls the ANProgram executer if the called method is an ANProgram, and otherwise calls the ASProgram 
executer 1 24 to execute the called method. 

However if the object ciass was loaded from the untrusted object class repository 142, the class loader 136 ex- 
amines the object header of the object to determine if its object class includes any ASPrograms. It does so by deter- 
mining if there any native_ASProgram IDs in the virtual function table of the object. 

If there are no ASPrograms in the object class, then the class loader 136 calls the ANProgram integrity verifier 
136 to verify the integrity of the ANPrograms in the object class. This is done in the same manner and for the same 
purpose as was described earlier for verifying the integrity of the ANProgram 200 (in the section discussing compiling 
55 an ANProgram). Thus, if the integrity of any of the ANPrograms is not verified, then the ANProgram integrity verifier 
passes back to the ctass loader a failed result and the class loader aborts the class loading procedure and generates 
an appropriate message indicating this. But. if the ANProgram integrity verifier sends back a passed result indicating 
that all of the ANPrograms of the object class are verified, the class loader enables execution of the called method. 
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, o .^,^n thP Class loader 1 36 calls the signature verifier 1 32 to verify 
„ there are ar.y ASPrograrT,s .n the o^'^^^^'f ^ ^^^^^^^^ fgna Dig.talSigr.aturecP " any of the ASPrograr^s 
the comp-ler s.gnature Dig..a.Signaturec ^^^^ Jjj^^^^^^^^if .ntegrlty of the ASPrograrp's source cannot be 
does not include a D.g.talS.gnaturecP and ^ ^f^J^^'.^^NProgram executer a failed result. In response, the 

verified and therefore the signature vent.er ^^^^^^ ^Lr^.es an appropriate rr^essage that this has occurred 

Cass loader aborts the ob,ect class loading PJ^^^f ^^^^^^^^ ^ DigltaSignaturecp and a DlgitalSignaturec. the 

Further, rt all of the ASPrograrr,s .n the object ^'^J^ °° '"^^^^^^^^ digital s.gnatuTes. are compared with the lists 
identities of the CompParty and the ^o-P-'^r as ind^^^^^^^ ;,sPrograrT,s ,h the obiect class 

1 44 (see Fig. 1 ) of known, trusted Compiler Parties and trusted Cornp y ^^^.^^ 

weri compL by a CompParty or a Comp.^r not -^"^^J^J^, ^^^^f^^^^lL method is thereby blocked. Similarly, if 

the Identified CompParty and Compiler for ^";^«^^^ff;°9;7;3p'^g,3a, Executer. then the signature verifier venues 
ASLanguage used by all the ASPrograms "^^^"^ ^^^^^^^ the DigitalDignatureop (in the section d.s- 

these signatures in a similar manner as -^^^^^J^^'^^^^.^^^Lse^ and CompParty's public keys are re- 

cussing compiling the ^NProgram 200)^ However^ n thi^^c^^^^^^^ P HashFunctionc ID m the 

trieved from the trusted key repository 106 and Respectively u Furthermore, the test message 

Wied by the decrypted HashFunction, ID ar,d HashFunct.^^^^^^^^ ^ ^^^^^^ ^^^^ ^ ^^3,^Dcp) 

IftheDigitalSignaturecand/ortheDigitalS gnature^^^^^^^^^ ,n response, 

for every ASProgram, then the signature ^'"'^'''ll'l^^^^^^ message that this has occurred. 

the Class loader aborts the class '<^^'''^ ^Zt^^^^^^^TeTa^e^^^^ (i.e., MDc = TestMDc and MDcp = 

However, if the DigitalSignaturec and ^^'artalS jaturecp are^ y ^ ^^^^^^ .^.^^ to verify the 

TestMDcp) .or every ASProgram. then ^^^^^^^-^^^^^^^^^^ the ASPrograms were compiled. To verify 

OrigPartys signatures (DigitaSignatureopHor the An ^^^^ ^^^^^ ^.^^^^3^^ ^3,,^, 

the OrlgParty digital signatures, the DigitalSignatureop of each 

in the section concerning compilation of ^1;^^'°^'^"'''^^^ ^^^^^ j^e ASPrograms were compiled is verified, then 

„ the DigitalSignatureop of each of '^^'^''''''^^l''^^ every ANProgram in the object class and 
the class loader calls the ANProgramintegrity verrfier to ven^^^^^ ^^^^ ^^^^^^ ^33,,bed 

the ANPrograms from which the ASPrograms were ^°";P' ^f^^ ANProgram integnty verifier sends back to 

.j:^^::^^:^'^!^^' —.l ....... ^ - 

Program executer to execute the called method, as aPP^°P"ate. ^„^,^^^ecl object classes in the untrusted 

',n View of the foregoing, the ExecuterParty is digital Signatures can be verified will 

repository 142 that have integrity verifiable ANPrograms and ASPrograms who g 
be loaded and have their programs executed. 

Alternative Embodiments 

S^. o, me o, m. «.en,.n a.ov, a. op«a., T.... «se sK,« «.» 

m„ ,l»,na.i». .mbod™nls exist Ih.l f"l";':^'^'',^Xl'„„^,^t^ both . O.g.alS.gna.u.e,,, and a D.gllal- 
For exa,„ple, me ANP«=sram comp.le- »as « „ „^^,, ,„e ANProgram oomp«e. couH be 

"n=v'r;;=.°;;:a=^^ 

Dlgil.lSigr>a.>.rec However, me prc^r.m '^l^',;^^^^^^^ ASProgram be.n, ver.li.d ir>cWes «. Fu„r,er. 
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When the ExecuierParty is the OngParty. the ExecuterParty knows that it actually sent the ANProgram 200 to the 
CompParty's server computer i04 to be compiled into the ASProgram 300. In this case, the class loader 1 36 could be 
constructed to not call the signature verifier to verify the DigtialSignatureQp in the ANProgram. Rather, the Execuier- 
Paay can simply compare the DigtialSignalureop in the local copy of the ANProgram with the DigtialSignatureop in 
the compiled ASProgram. Additionally, the class loader could be constructed to not call the ANProgram integrity verifier 
1 26 to verify the integrity of the ANProgram corresponding to a called ASProgram since the integrity of the ANProgram 
would have been checked during the preparation for compiling procedure prior to being sent to the compiling server 
computer. Altematively, the ANProgram compiling preparer 1 28 could be constructed to not call the ANProgram integrity 
verifier during the preparation for compiling procedure since its integrity would be checked both by the compiler and 
when the class loader calls the ANProgram integrity verifier prior to execution of the corresponding ASProgram. 



TABLE 1 

Pseudocode Representation of Method of Preparing Architecture 
Neutral Program for Compiling 

Procedure: Prepare for Compiling (ANProgram code, OrigParty's PrivateKey, and 
OrigParty's ID) 
{ 

Verify integrity of ANProgram with ANProgram integrity verifier 
If failed result 

{ abort and generate failed result message } 
Generate MDqp = HashFunctionop (ANProgram code) 

Generate DigitaiSignatureop = Encrypt (MDqp + HashFunctionop ID. OrigParty's 

PrivateKey) + ClearText (Orig Party's ID) 
Append DigitaiSignatureop to ANProgram code 
Generate message that ANProgram is prepared for compiling 
Retum 

} 
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TABLE 2 



Pseudocode Representation of Method of Compiltng ANProgram and 
Generating ASProgram 

. rnmnile (ANProgram. CompPartys ID. ASLanguagelD. CompParty s 
'"^^SeS^^^^^ '0. -d Cc.pi.e.s PHvateKey) 

Ueve OrigParty-s Publ.cKey from tn^sted Key repository using C.earTexf 

OrigParty-s ID in DigitalSignatureop nrioPartv s 

Decrypt HashFunctiono. ID in DigitalS.gnatureop. OngParty s 

Generate Te^MDoP = HashFunctionop (ANProgram code) using 

HslufL^^ Identified by decrypted HashFunctionop ID 
Compare decrypted MDqp and TestMDop 
If decrypted MDop * TestMDop 

r DigitalSignatureop of OrigParty not verified •/ 

Generate failed result message 

} 



Else 



r DigitalSignatureop of OrigParty has been verified ;/ 

Verify integrity of ANProgram with ANProgram .ntegnty venfier 

If failed result 

ibort and generate failed result message 



} 



Else 



1* ANProgram has been verified */ 

Compile ANProgram code into ASLanguage identified by 

ASLanguage ID to generate ASProgram code 
Generate MDc = HashFunctioncs (ASProgram code + 

DigitalSignatureop) 
Generate DigitalSignaturec = Encrypt (MDc + HashFunctionc ID. 

ANProgrom Compiler's PrivateKey) + ClearText 

ANProgram Compiler's ID 
Generate MD^p = HashFunctioncp (ASProgram code + 

DigitalSignatureop + DigitalSignaturec) 
Generate DigitalSignaturecp = Encrypt (MDcp * HashFunct.oncp 

ID. CompParty s PrivateKey) + ClearText CompParty's ID 
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Generate and Return File or Object containing: 

ANPragram Code. 

DigitalSignatureop, 

ASProgram Code. 

DigitalSignaturec, and 

DigitalSignatureop 
/* ASProgram has been compiled and generated 
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TABLE 3 

Pseudocode Representation of Method of Executing 
Architecture Specific Program 

Procedure: Execute (ObjectClass. Program) 

If the Program is a verifiable program 

{ Execute Program using the Bytecode Interpreter } 

^"^{ Execute Program using the compiled program executer } 
} 

Procedure: ClassLoad (ObjectClass. Program) 

Object Class has already been loaded into ExecuterPart/s address space 
Call Execute (ObjectClass. Program) 



25 Return 
} 



55 



r The Object Class has not been loaded '/ 

Load Object Class into ExecuterParty's address space 

1; Object cLs was loaded from Tested Object Class Repos.tory 

Call Execute (ObjectClass. Program) 

Return 

} 

/. Object Class was loaded from Untrusted Object Class Repostory */ 
If Object Class does not contain any ASPrograms designated as 
native_ASPrograms in Object Header of Object 

lerify integrity of all ANPrograms of Object Class with ANProgram integrity 

verifier 
If failed result 

Abort with appropriate failed result message 
} 

Integrity of all ANPrograms of Object Class have been verified V 
{ Call Execute (ObjectClass. Program) } 
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Return 
} 

r Object Class does contain ASPrograms designated as native_ASPrograms in 

Object Header of Object •/ 
If any ASProgram does not contain a DigitalSignaturecp and a DigitalSignaturcc 

/* Compiling Party and Compiler of every ASProgram cannot be verified */ 

Generate appropriate message 

Retum 

} 

For each ASProgram in Object Class: 

{ Determine identity of CompParty and Compiler and determine 
ASLanguage used by ASProgram } . 

If identity of CompParty for any ASProgram is not a known, tmsted. Compiling 
Party, or the identity of Compiler is not a known, trusted Compiler, or the 
identified ASLanguage is not one used by the ASProgram Executer 

{ 

Generate appropriate message 

Return 

} 

For each ASProgram in Object Class: 
{ 

Retrieve CompParty's PublicKey from trusted key repository using ClearText 

CompParty's ID in DigitalSignaturecp 
Decrypt (MD^p + HashFunctioncp ID in DigitalSignaturecp, CompParty's 

PublicKey) 

Generate TestMDcp = HashFunctioncp (ASProgram code + DigitalSignatureof 
+ DigitaiSignaturec in ASProgram) using HashFunctioncp identified by 
decrypted HashFunctioncp ID 

Compare decrypted MDcp and TestMDcp 

} 

If decrypted MDcp * TestMDcp for any ASProgram 
{ 

t* DigitalSignaturecp for every ASProgram has not been verified */ 

Generate appropriate failed result message 

Retum 

} 

/* DigitalSignaturecp for every ASProgram has been verified'/ 
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For each ASProgram in Object Class: 

Comptte^sPubncKey) ,ASProaram code + DigitalSignatureop) 

compare decvPted MD^ and TeslMOc 
„ aic-ypled MO. . TestMDe lo. any ASPr^ram 

5. D,«-e. .or ^ ASPro,.™ ,n 0*C Cas. ^ no. .een 

verified '/ ^^^^ 
Generate appropriate failed result message 

Return 

• ri?i<;s has been verified */ 
For each ANProgram .rom »h,ch an ASProgram 

Uva Od,Par.y. Pub.^a, .ron, .,us.ed raposHon, us.n, OearTe^ 

PublicKey) KPnortion (ANProgram code) using 

=-HS^p;rn:rd=r:."^^edHaVu„*n.,o 

compare decrypted MD^p and TestMDoP 
,f decrypted MDop • TestMDoP for any ANProgram 

oigitaiSignature. for eve^ ANProgram from ..ich an ASProgram in 
Object Class was compiled not verified / 
Generate failed result message 



45 Return 
} 



. me D„i.,S„na.ure. ,n every ^^^^^.T^^^^^^^^^ 

^'^^rpr::fnor«-^^^ 

If failed result 
( 
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Generate failed result message 

Return 

} 

/* Integrity of all ANPrograms in Object class and all ANPrograms from which 

ASPrograms in Object Class were compiled have been verified */ 
Call Execute (ObjectClass, Program) 
} 



Claims 

1. A computer comprising: 

a program integrity verifier that verifies that programs written in an architecture neutral language satisfy pre- 
defined program integrity criteria: 

a digital signature verifier that verifies the digital signatures of originating parties of programs that are contained 
in the programs: 

an untrusled object class repository that stores untrusted object classes: 
a trusted object class repository that stores trusted object classes: 

said object classes each including at least one program, each program comprising a program selected from 

the group consisting of (A) architecture neutral programs written In the architecture neutral language and (B) 

architecture specific programs written in an architecture specific language whose integrity cannot be verified 

by the integrity verifier: 

an architecture specific program executer: 

an architecture neutral program executer: 

a user address space: and 

a class loader that loads a specified one of said object classes into the user address space for execution when 
execution of any program in the one object class is requested, said class loader including program security 
logic for preventing the loading of any requested object class, other than object classes in said trusted object 
class repository, that includes at least one architecture specific program unless every architecture specific 
program in the requested object class includes a digital signature and said digital signature is successfully 
verified by said digital signature verifier. 

2. The computer of claim 1 . said class loader includes verifier logic for invoking said program integrity verifier to verify 
the integrity of every architecture neutral program in the requested object class when the requested object class 
is not stored in said trusted object class repository and includes at least one architecture neutral program: 

said program security logic further preventing the loading of said any requested object class other than object 
classes in said trusted object class repository when the requested object class includes at least one architecture 
neutral program whose integrity is not verified by said program integrity verifier 

3. The computer of claim 1 

each said digital signature associated with one of said architecture specific programs including a signing party 
identifier and an encrypted message, said encrypted message including a message digest of the architecture 
specific program generated using a message digest function wherein said encrypted message has been en- 
crypted using a private encryption key associated with said identified signing party: and 
said digital signature verifier including logic for processing a specified digital signature by obtaining a public 
key associated with the signing party identified by said signing party identifier, decrypting the encrypted mes- 
sage of said digital signature with said public key so as generate a decrypted message digest, generating a 
test message digest by executing said message digest function on the architecture specific program associated 
with said digital signature, comparing said test message digest with said decrypted message digest, and is- 
suing a failure signal if said decrypted message digest and lest message digest do not match. 
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4. The computer of claim 1 



70 



15 



20 i 



.«,d oroaram security log.c further (or preventing the loading of any requested object class other than object 
faiesTsTid uu"^^^ ob,ect class repository, that includes at leas, one architecture specific P-9;a- unless 
eveTarchSure specific prograr. .n the requested ob.ect Cass Includes two digital signatures and sa.d digital 
«innatures are both successfully verified by said digital signature verifier; 

^ach sa d d^Ll s gnature associated with one of sa.d architecture specific programs including a signing party 
each said digital s'gnaiure encrypted message including a message generated by a predefined 

Zf~::r^^^^^^^^ — -^-^ ^ ^-^'^ 

S dSirsSurele^iLMnciuding logic for processing a specified digital signature by obtaining a public 
Tev a si a 2,": "the party'dentified by said signing party identifier, decrypting the -crypted mes- 

.^^It^ Ltol sianarure wUh said public key so as generate a decrypted message, generating a test 
sage of ' ^'f^^'^^^^^,,^ procedure on the architecture specific program associated with said 

^gSrrgniuTcrparg'sJirs^^^^^ With said decrypted message, and issuing a failure signal ., 

rusteTo J^cTas Tep^^ unless every architecture specific program in the -'^-^^'^^ °f 'j'^ . 
dudes a S^s^ digital signature for which the signing party is a member of a first group of trusted Pa^-es. 
ndudeJ a second digital signature for which the signing party is a member of a second group of trusted parties. 



25 



30 



s^d'tc^qram e^^^^^^^^ 'oQic preventing loading of the requested obiect class, other than object classes in 
" said tru ?eS Ob e'cTc a reposU unless every architecture specific program in the ^^<^^-^'^^ ^^^^'^^^^ 
cfudel a message digest for an associated architecture neutral program, and said message digest -^^ "^hes ^ 'est 
message d^est'generated by said program security logic by performing a predefined message digest procedure 
on said associated architecture neutral program. 

6. A method of operating a computer system comprising the steps of; 

storing untrusted object classes In an untrusted object class repository; 

storinq trusted object classes in a trusted object class repository; ^„,„^,«rt from 

said Ob let classes each including at least one program, each program comprising a program 
thfgX consisting of (A) architecture neutral programs written in an architecture neutral language and (B) 
« architecture specific programs written in an architecture specific language; 

lerexecutln o any program in the one object class is requested, loading the requested object class into 
Tuser address space for execution unless loading of the requested object class is prevented by a secun y 
Jiol JioffncTuding preventing the loading of any requested object class, other than object c'asses in sa^ 
SlTob ec, class^epository that includes a. least one architecture specific program unless every arch tec- 
turfspectc pSarn 'n theTequested object class includes a digital signature and said digital signature is 
successfully verified by said digital signature verifier 

^qleLte'd oSect Class, unless the requested object Cass is in said trusted <^^^^::''^ 
quested object class includes at least one architeCure neutral program whose integrity is not verified. 



40 



45 



8. The method of claim 6.. 
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.=,.h c^iH Hinit^i sianature associated with one of said architecture specific programs including a signing party 

drtira^d'irerypr^^^^^ 

specific program generated using a message digest function wherein said encrypted message has 
Jr.,r.,^H n<=,nn a orivate encryption key associated with said identified signing party, and 
slToZT'!ss ^^^^^ processing a specified digital signature by obtaining a public key as- 

sSatd w th the s^n ng party identified by said signing party identifier, decrypting the encrypted -es^je of 
rSrSgnature w^said public key so as generate a decrypted message ^f/^' ^^^^^^^^^^^^^ 
sage d^st by executing said message digest funCion on the architecture specific program associated with 
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TfL'lluJfliTif '"'h "^^^^^9^ ^'^h ^a.d decrypted message digest, and .ssu.nc 

a failure s.gnal ,f said decrypted message o.gest and lest message digest do not match. 



9- The method of claim 6. 
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12. 

55 



Object Class loading step including preventing the loading of any requested object class, other than object 
classes .n sa.d trusted object class repository, that includes at least one architecture specific program unless 
every architecture specific program in the requested object class includes two digital signatures and said digital 
signatures are both successfully verified by said digital signature verifier 

tri^nr^T ^'^"^'""'^ associated with one of said architecture specific programs including a signing party 

identiner and an encrypted message, said encrypted message including a message generated by a prede^ned 

,T:? "^"^ '"'^'''^ ^"'^^P'"^ "^'"9 ^ '"'^^P'-- associated 

with said identified signing party: 

said Object class loading step including processing a specified digital signature by obtaining a public kev as- 
sociated with the Signing party identified by said signing party identifier, decrypting the encryp^d message of 
said digital signature with said public key so as generate a decrypted message, generating 1 terr^essaqi 

nature'cror '"wf °" "^^ '''''''' '---'^^ with saSd^S Jfg' 

ed lc!r^H ^"^f J^" '^'^ ^^'^'^P'"^ "^^=^^9^- '=«"*"9 - Signal if said decrypt- 

ed message digest and test message digest do not match sd'o Decrypt 

Jhil^?,r' '""='"^'"9 P^«^«"'*"9 loading of the requested object class other than 

object Classes in sa.d trusted object class repository unless every architecture specific program in the requel- 

trul?n.f " '"h"'? ' "•^"^'^ P^^y - - -e-ber of a fi sf group o, 

groTp onr:;Lt:dTa;ir ^ ^'^""-^^ ^^'^^ ^'^"^-^ '^^^^ ^ --"^^ °' ---^ 

10. The method of claim 6. 

ri..J^"' "'^^ '"^'"'^'"9 P^^^«"''"S loading of the requested object class, other than object 

c lasstnldef. m T ^^^^ architecture specific program in the requested ob ec 

class includes a message digest for an associated architecture neutral program, and said message digest matcLs 

cedu e on safd T7T '^'^'^""^ ^ P-'^^'--^ me' sage d gest pro 

cedure on said associated architecture neutral program. y a k"" 

A memory for storing data programs being executed on a data processing system, said memory comprising: 

a program Integrity verifier that verifies that programs written in an architecture neutral language satisfy pre- 
defined program integrity criteria: ^ =>aiP5.iy pre 

Tn progTrJ^r ''''''' °' "'^'"^'"^ ^^"'"^ °' P'^S^^"^^ 

an untrusted object class repository that stores untrusted object classes: 
a trusted object class repository that stores trusted object classes 

said object classes each including at least one program, each program comprising a program selected from 
the group consisting of (A) architecture neutral programs written in the architecture neutral language and S 
S thlTnt^gr^y rerLr""^ ^" "'^'"^""^^ '^"^"^^^ cannot be verifLj 

an architecture specific program executer: 
an architecture neutraf program executer: and 

execu?iornf 1 ^ °' ^'^'^^^ ^ ^^^^^^^ ^Pa'^e execution when 

tn^tTr^ ' requested, said class loader including program securuJ 

instructions for preventing the loading of any requested object class, other than object classes .n said trusted 
ob,ect Class repository, that includes at least one architecture specific program unless every architec tu L sle 

verified by said digital signature verifier ^^^^^tuuy 
The mernory of claim 1 1 said class loader includes verifier instructions for invoking said program integrity verifier 

l^rn lrn ^^'d.'f-sted Object Class repository and includes at least one architecture neutral program 

said program security instructions further preventing the loading of said any requested object class other 
than Object classes in said trusted object ctess repository when the requested object class included a' Sasr^e 
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(57) A computer system includes a program execut- 
er that executes verifiable architecture neutral programs 
and a class loader that prohibits the loading and execu- 
tion o( non-verifiable programs unless (A) the non-veri- 
fiable program resides in a trusted repository of such 
programs, or (B) the non-verifiable program is indirectly 
verifiable by way of a digital signature on the non-veri- 
fiable program that proves the program was produced 
by a trusted source. In the preferred embodiment, veri- 
fiable architecture neutral programs are Java bytecode 
programs whose integrity is verified using a Java byte- 
code program verifier. The non-verifiable programs are 
generally architecture specific compiled programs gen- 
erated with the assistance of a compiler. Each architec- 
ture specific program typically includes two signatures 
including one by the compiling party and one by the 



compiler. Each digital signature includes a signing parly 
Identifier and an encrypted message. The encrypted 
message includes a message generated by a prede- 
fined procedure, and is encrypted using a private en- 
cryption key associated with the signing party A digital 
signature verifier used by the class loader includes logic 
for processing each digital signature by obtaining a pub- 
lic key associated with the signing party, decrypting the 
encrypted message of the digital signature with that 
public key so as generate a decrypted message gen- 
erating a test message by executing the predefined pro- 
cedure on the architecture specific program associated 
with the digital signature, comparing the test message 
with the decrypted message, and issuing a failure signal 
If the decrypted message digest and test message di- 
gest do not match. 
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